Method and apparatus for integrated testing of software

专利摘要:
PURPOSE: A method and tool for automating an integrated software test are provided to automatically generate the test data based on an interaction between the tasks described by a message sequence chart and to automatically execute the generated test data. CONSTITUTION: The interaction between the tasks of an embedded software is described by using the message sequence chart. The transition between a system state and a message sequence state obtained by the execution of the message sequence charts is converted into a GFSM(Global Finite State Machine)(s102). A test sequence to visit all states and transitions of the system is generated from the generated GFSM(s104). The generated test sequence is executed by using a test driver realizing on a simulator of the embedded software(s106). In order to examine a test result, a native test driver and a Java test driver are monitored(s108).
公开号:KR20020095723A
申请号:KR1020010033906
申请日:2001-06-15
公开日:2002-12-28
发明作者:박기웅；홍인표；신석종；강제성；김태효；이남희；차성덕
申请人:삼성전자 주식회사；
IPC主号:

专利说明:

Automation methods and tools for software integration testing {Method and apparatus for integrated testing of software}
[17] The present invention relates to integrated testing of software, and more particularly to software integrated testing that automatically generates test data based on interactions between tasks described by a message sequence chart, and automatically performs generated test data. The present invention relates to an automated method and tool.
[18] Digital TV software is a kind of embedded software. In the past, test scripts for unit testing and integration testing required for testing embedded software have been manually generated.
[19] Patent 1999-27345 filed by Applicant (July 7, 1999, titled: Systems and Methods for Testing Embedded System Software) describes a method for automatically generating test scripts for unit testing. . However, the decision table description method disclosed in the above patent application cannot be used to prepare the specification for the integrated testing, and the expression power of the mesh sequence chart used in the patent application alone is used to prepare the specification of the whole software for the integrated testing. There was a lack.
[20] The present invention has been made to solve the above problems, and software integration testing that automatically generates test data based on interactions between tasks described in message sequence charts, and automatically performs generated test data. An object of the present invention is to provide an automated method.
[21] Another object of the present invention is to provide an apparatus suitable for the above method.
[22] Another object of the present invention is to provide a method for determining the behavior automata suitable for the above method.
[1] 1 is a flow chart showing an automated method for software integration testing according to the present invention.
[2] FIG. 2 is shown to show the configuration of an automated device for software integration testing according to the present invention performing the method shown in FIG. 1.
[3] 3 shows an interface screen of the MSC editor 202 shown in FIG.
[4] 4 shows an interface screen of the test sequence generator 204 shown in FIG. 2.
[5] FIG. 5 is shown to show the detailed configuration of the native test driver 208 shown in FIG.
[6] FIG. 6 is shown to conceptually illustrate the operation of the Java test driver 206 shown in FIG.
[7] 7 shows a configuration of digital TV software to which an embodiment of the present invention is applied.
[8] FIG. 8 shows hierarchically the description of the digital TV specification shown in FIG. 2 using an MSC.
[9] 9 shows a scenario of processing six remote control or mouse selection inputs.
[10] 10 shows an application termination scenario.
[11] 11 to 13 show scenarios when currentApp is AL_APP_NONE, AL_APP_BROWSER, and AL_APP_EPG, respectively.
[12] 14 shows an example of bMSC.
[13] FIG. 15 shows an example of converting a bMSC shown in FIG. 14 into a simple message graph.
[14] FIG. 16 shows the behavior automata obtained by applying to the simple message graph shown in FIG.
[15] FIG. 17 shows an automaton generated by using a higher bMSC shown in FIG. 10.
[16] FIG. 18 shows the GFSM obtained by performing the GFSM generation algorithm on the overall behavior automata shown in FIG. 17.
[23] Automation method for software integration testing according to the present invention to achieve the above object is
[24] In a method for automatically generating test data based on interactions between tasks described by a message sequence chart, and automatically performing integration testing based on the generated test data,
[25] (a) describing interactions between tasks of embedded software using message sequence charts;
[26] (b) converting a transition between a state of a system that can be obtained by performing a plurality of message sequence charts and a state of a message sequence into a global finite state machine (GFSM);
[27] (c) generating a test sequence from the written GFSM that can visit all states and transitions of the system; And
[28] (d) performing the generated test sequence using a test driver implemented on a simulator of embedded software.
[29] Automation device for software integration testing according to the present invention to achieve the above another object is
[30] An apparatus for automatically generating test data based on interactions between tasks described by a message sequence chart and automatically performing integrated testing based on the generated test data.
[31] Create a message sequence chart describing the interactions between tasks in the embedded software, and use the Global Finite State to show the transitions between the state of the system and the state by the sequence of messages that can be achieved by the execution of the various created message sequence charts. Message sequence chart editor for converting;
[32] A test sequence generator for generating a test sequence capable of visiting all states and transitions of the system from the created GFSM; And
[33] It is implemented on a simulator of embedded software, characterized in that it comprises a test driver for performing a test sequence generated by the test sequence generator.
[34] The act automata determination method according to the present invention to achieve the above another object is
[35] In the method of determining the behavior of the system-wide behavior automata based on the interaction between the tasks described in the Message Sequence Chart,
[36] (b-1) obtaining a behavior automata for the currently active bMSC;
[37] (b-2) obtaining state variables appearing in the behavior automata;
[38] (b-3) the initial value of each state variable as an initial configuration of the system and put in a stack;
[39] (b-4) It is characterized by including the step of creating a GFSM by repeating the process of creating nodes and transitions until the stack is empty.
[40] According to the method for automating software integration testing according to the present invention, the function of each unit module is described using a decision table, and the calling path of the module is described using a basic notation of a message sequence chart. The message sequence chart and decision table described are analyzed and the results are combined to select the test data and output it in the form of a test script.
[41] Hereinafter, the configuration and operation of the present invention will be described in detail with reference to the accompanying drawings.
[42] As the demand for providing various services for embedded systems increases, the scale of embedded software for accommodating them becomes larger and more complex. Moreover, there is a change from the existing C language-oriented implementation method to the implementation of object-oriented languages such as Java, and there are systems in which the two languages are mixed. The more complex the software, the more difficult it is to perform manual testing. Unit testing in embedded software is testing for each task, and integration testing is testing of interactions between tasks. Task-level testing can be achieved by applying various testing techniques and automation tools developed so far, but testing has been mainly performed manually because there is no automation tool that supports integrated testing. Moreover, there was no automatic testing tool that considered both C and Java languages together. In order to overcome this problem, the present invention proposes an integrated testing automation method of software implemented in C and Java.
[43] 1 is a flow chart showing an automated method for software integration testing according to the present invention.
[44] According to the method shown in FIG. 1, the interaction between the tasks of the embedded software is first described by using the MSC (Massage Sequence Chart), and the system state and message sequence that can be obtained by the execution of several MSCs are written. The transition between states is converted into a global finite state machine (GFSM). (s102)
[45] Tasks that use Fist In First Out (FIFO) queues for interaction between the tasks that make up the embedded software are:
[46] 1. Initialize the task.
[47] 2. Repeat the following steps until you shut down the system.
[48] (a) Get a message from the front of the message queue. If the queue is empty, the task blocks.
[49] (b) Take appropriate action on retrieved messages. If there is a message to be sent to another task, it is put in the message queue of the target task.
[50] Tasks that use the asynchronous message transfer method using a FIFO queue must take one input and wait for another to wait in the queue to complete processing. Therefore, when the execution process according to the type of message is prepared in a separate scenario and combined, a message transmission / reception specification of the entire system can be created.
[51] That is, the task of each task is not subjected to interference of other scenarios in performing the scenario according to the type of the received message.
[52] For the above scenario specification, the present invention follows the MSC standard defined in ITU-T Z.120 as it is, but extends the following points. In addition, the present invention uses five syntaxes of 'Instance', 'Message', 'Reference', 'Alt Inline', and 'Condition' for specification of embedded software among many expressions provided by Z.120.
[53] 1. Instance: Describes the task or thread to be specified. In the case of Java thread, distinguish by using ':' before the name.
[54] 2. Message: Describes the sending and receiving of messages between tasks. At this time, the parameter value of each message is described in the following format.
[55] Message name (parameter name = parameter value, ,,,)
[56] When testing is executed, input message is sent to the task to be tested by using 'message name' or monitoring is performed. Also, by using the 'parameters' used in the actual implementation, the abstraction difference between the implementation and the specification is corrected.
[57] 3. Reference: indicates a reference to another bMSC.
[58] Alt Inline: Describes an optional scenario that can be executed. In addition, the details of each item of Alt Inline should be described by reference, and the items constituting alt should be written completely. That is, the number of all cases of the condition to be compared should be described.
[59] 5. ondition: describes the activation condition that determines whether or not the scenario is to be performed, or describes the state change of the system by the transmission of a message. This is used as additional information to obtain status information when generating GFSM.
[60] The format is as follows:
[61] State variable = value
[62] It is also written with asserts to describe the state change of the system due to the transmission of a message.
[63] assert state variable = value
[64] In MSC 2000, an extended version of MSC '96, the activation condition should be expressed using 'when', and if the value of the state variable 'Variable' is equal to 'Value' when the existing 'Condition' is encountered, the process continues. Otherwise, do not perform the scenario. The description of 'Condition' in the form of 'variable-value' implies a change of state variables. In other words, if a 'Condition' is encountered during the execution of the scenario, the value of 'variable' is changed to 'value' and the scenario continues.
[65] The set of all processes constituting the system is represented by P, the set of events by E, and the set of names by Σ. Where the set of events E is
[66] to be.
[67] Represents a set of message events silver
[68] Consisting of: Sends a message, Indicates a received message.
[69] Each sent message Function Is applied, the corresponding received message Can be obtained. condition representing a set of events Consisting of: Is an event that indicates the scenario activation condition, Is an event that represents a state variable change. Finally and Are events representing the reference and the altinline, respectively.
[70] Σ set of names
[71] It consists of. Is the name of the bMSC, Indicates the name of the instance. The name of an instance can be the name of a native task or a Java thread. The name of the Java thread can be used in front of the name to distinguish it from the native task. Indicates the name of the message, and has the form 'message name (parameter name = parameter value, ...}', but is considered one name here. The 'message name' used when performing the actual testing By inputting or monitoring the task to be tested, and by using the name and value of the actual available variable in the 'parameter', the abstraction difference between the implementation and the specification can be corrected. Indicates the name of the condition.
[72] V the set of state variables, and the area of each state variable State assignment function If the relationship between the state variable and the value is relop , the condition statement Is described. At this time, the condition for each state variable is interpreted as a product, and the available relop is limited to '='. The condition used as the scenario activation condition uses the conditional expression as it is, and the condition used in the state variable environment can be distinguished by prefixing the 'assert' before the conditional expression.
[73] The MSC, which represents the structure of the entire MSC,
[74] It can be defined as, each meaning is as follows.
[75] One. Is a set of bMSCs (scenarios).
[76] 2. Is bMSC representing the top-level scenario.
[77] 3. Is a set of names for bMSCs.
[78] 4. Is a function that assigns a name to each bMSC.
[79] 5. Denotes a reference relationship between bMSCs.
[80] In addition, each unit scenario Is
[81] The meaning of each is as follows.
[82] One. Is The set of instances that make up the.
[83] 2. Is A set of events that make up a.
[84] 3. Is A set of names that make up a.
[85] 4. Is a function that assigns each event to an instance. In the case of a message, it is assigned to only one instance. But in the case of condition, reference, alt inline Assume that is assigned to.
[86] 5. Is a function that assigns a name to each instance and event. At this time Assumes that only the name of the corresponding item is assigned. It does not assign a name for the message of the instance.
[87] 6. Indicates the order between the events. At this time, Each instance Have the same value The order relationship between them.
[88] Next, generate a test sequence that can visit all states and transitions from the GFSM (s104).
[89] When using MSC to describe native tasks and Java threads implemented in C language, they can be expressed naturally in a single MSC. Until GFSM generation, it has information about native and Java together, but test sequence is generated separately and executed by native and Java test driver respectively. The test sequence generated from the GFSM is described in script form. In the present invention, five types of scripts required for integrated testing of embedded software are defined and used.
[90] Both Java and native use the same type of script. However, in the Java thread constituting the embedded software, external input events are always delivered through native tasks, so message and data are not used.
[91] 1.message from to name parameter1 value1 ,,,
[92] Used to give an input event from an external environment (ENV) to a testing target task (IUT). 'to' means the IUT task to receive the message, and 'name' means the event transfer function used by the embedded software to be tested.
[93] Monitor from to name parameter1 value ,,,
[94] It is used to monitor the transfer of events between IUT tasks. The format is the same as in message. At this time, 'from' refers to a task that transmits an event to the IUT task. Some event transmission functions may not support 'from'.
[95] 3.condition task variable = value
[96] This is used to check whether the system is in a proper state before GFSM transitions, or interactions between tasks.
[97] Assert task variable = value
[98] Used to indicate test conditions after performing an interaction.
[99] 5.data variable1 value variable2 value2 ,,,
[100] Used to know in advance what data to use for the current test sequence. This is not necessary in embedded software that uses only simple input events. However, if you need complex input data, you can prepare the data to be used beforehand and use it when you encounter this type of script.
[101] The generated test sequence is performed using a test driver implemented on a simulator of embedded software (s106).
[102] The native test driver and the Java test driver are monitored to check the test result (s108).
[103] In the present invention, native and Java monitoring methods are presented to check the results of testing. In general, event transmission is done by using a specific function in native, so you can implement monitoring function in this function. However, in the case of Java, since there is no separate method for transmitting an event, the present invention uses a method of manually implementing monitoring code in source code.
[104] Obtain a test result performed by the test driver (s110).
[105] FIG. 2 is shown to show the configuration of an automated device for software integration testing according to the present invention performing the method shown in FIG. 1.
[106] In FIG. 2, reference numeral 202 denotes an MSC editor, 204 denotes a test sequence generator, 206 denotes a Java test driver, 208 denotes a native test driver, and 210 denotes a TS (Transport Stream) generator.
[107] The MSC editor 202 edits MSC items, and is implemented using Java in an embodiment of the present invention. The implemented MSC editor has an interface screen as shown in FIG. In the present invention, since the GFSM is generated by synthesizing a plurality of bMSCs, the implemented MSC editor 202 includes a project function for managing multiple bMSCs. On the left side of the interface screen shown in FIG. 3, bMSCs (basic MSCs) constituting the project are shown in a tree format. The icon panel shown in the middle is a collection of icons for drawing bMSCs and can draw the five items mentioned above ('Instance', 'Message', 'Reference', 'Alt Inline', and 'Condition'). If you click the bMSC in the project tree twice in a row, you can create the bMSC on the right side of the screen. GFSM can be generated by selecting the top bMSC and selecting 'Generation' from the menu.
[108] Much effort has been made to express the behavior of scenarios using the structural information of the MSC. Scenarios for describing scenarios include the MSC of ITU-T and the sequence diagram of UML. The sequence diagram has the advantage of providing asynchronous as well as synchronous message transmission method, but it has difficulty in formalization. On the other hand, MSC, a formal specification language, is a language proposed for expressing communication between processes in SDL (Specification and Description Language), and focuses on asynchronous message exchange between processes. Recently, however, MSC has been widely used as a language for representing common scenarios.
[109] The syntax of MSC can be divided into basic MSC and high-level MSC. Basic MSC (bMSC) basically corresponds to syntax for expressing one MSC, and high-level MSC (hMSC) is used between these bMSCs. It is used to express the relationship of.
[110] Conventional testing methods based on MSCs serve as an aid in determining whether a MSC is a possible sequence when locating test sequences from a system model written in SDL, or time-consuming multiple parallel behaviors within a single MSC. There was a method of extracting a stamp and using it as a test sequence.
[111] The disadvantage of these methods is that one MSC describes only one scenario. In other words, the scenarios in which the systems appear are described in different MSCs, and the relationship between them cannot be expressed. Therefore, the system was limited to testing one system function at a time.
[112] In the present invention, by using more various expressions of the MSC, the contents of the specification can be faithfully used for testing, the GFSM is generated using the semantic information described in the MSC, and the number of states is minimized. A method of targeting is disclosed.
[113] Since scenarios are hierarchically linked in chapters, they should be linked to behavior automata. Since each item of alt is written in a separate bMSC for reference, the structure of the entire behavior automata can be completed by connecting the behavior automata obtained from the referenced MSC in the form of branch.
[114] At this time, since the completed behavior automata is based on location information, there are many states. In the present invention, a state (system configuration) is used by using values of variables used in a condition, and a GFSM is generated having one or more message sequences as transitions.
[115] The algorithm for generating GFSM is as follows.
[116] 1. Obtain the behavior automata for the currently active bMSC.
[117] (a) There are other bMSCs referenced here, and recursively determine the behavior automata for them.
[118] (b) Complete the overall behavior automata by linking the behavior automata for the lower bMSC to the behavior automata for the higher bMSC.
[119] 2. Find the state variables that appear in the behavior automata.
[120] 3. Set the initial value of each state variable to the initial configuration of the system and put it on the stack.
[121] 4. Repeat the following steps until the stack is empty to generate GFSM.
[122] (a) Remove a system configuration from the stack and restart it if it has already been done.
[123] (b) If it is a new system configuration, it displays the system configuration.
[124] (c) For each transition connected to the initial node of the behavior automata:
[125] i. If the name of the transition is a condition that asks for an activation condition, the current transition is stopped if it is not equal to the state variable value of the current system configuration.
[126] ii. If the name of the transition is an assert that changes the value of a state variable, change the value of that state variable in the system configuration.
[127] iii. If the transitional node is the end node of the behavioral automata, one transition of the GFSM is completed, so the system configuration at the initial node of the behavioral automata is moved from_state to the set of transitions of the behavioral automata under the name of the transition and the behavioral automata. Outputs to_state the system configuration at the end node of.
[128] iv. The above process is recursively performed for the next node that can be reached by each viable transition.
[129] The test sequence generator 204 implements a modified state and transition tour coverage algorithm among test sequence generation algorithms in the GFSM. The state tour coverage algorithm in embedded software means testing at least once every possible state of the system, and the transition tour algorithm means testing at least once every possible interaction.
[130] Traditional algorithms only need to create sequences that contain all states and transitions at least once. However, some test sequences generated by conventional methods are not suitable for automatic execution. That is, we need a way to run a test sequence and then make the sequence its initial state when we want to run a new sequence. Thus, the present invention used a method of generating a sequence such that all sequences start from the initial state of the system. In other words, only GFSM which has transition from initial state to initial state is used as input. This assumption is possible because embedded software typically defines and uses inputs that return the system to its initial state.
[131] The modified test sequence algorithm is a combination of a depth first search and a short test path algorithm. The detailed algorithm is as follows.
[132] 1. Mark all states (or transitions) as not visited.
[133] 2. Put the initial state of GFSM into a queue and create an empty path.
[134] 3. Repeat the following steps unless the queue is empty.
[135] (a) Get a state from the queue.
[136] (b) Obtain a state that can go from the imported state.
[137] (c) Find new ones (or transitions to the saved ones) that have not yet been visited.
[138] (d) Among the states (or transitions) that have not yet been visited, the first one is selected in the order entered, added to the route, and marked as visited.
[139] (e) Queue the selected state.
[140] (f) If a new state (or transition) is not available, output the path that has been progressed so far and the shortest path from the current state to the initial state, and then empty the path. The output is as follows.
[141] i. It collects all the conditions in the 'condition' statement of the MSC on the obtained path and outputs them in 'data' format at the beginning of the test sequence. The test driver references this to prepare the input data for testing.
[142] ii. Messages indicating a transition
[143] -If the event sending task is ENV, it is prefixed with 'message' and everything else is prefixed with 'monitor'.
[144] -If the event sending and receiving tasks are all Java threads starting with ':', the Java test script will output the rest to the native test script.
[145] iii. Compares the values of the variables before and after the transition and outputs all the values before the change in 'condition' format, then outputs the 'message' or 'monitor' corresponding to the transitions in sequence, and then displays all the values after the change Output in the form of assert '.
[146] 4. If any of the states (or transitions) have not been visited yet, queue the first of them in the input order and perform 3 again. If the state obtained is not the initial state, the shortest path from the initial state to this state is stored.
[147] An interface screen of the test sequence generator 204 implementing the modified test sequence generation algorithm in C ++ is shown in FIG. 4. In the interface screen shown in FIG. 4, the 'Graph' menu outputs an output for confirming the input GFSM in a graph format, and the 'Select ENV_IUT' outputs an output for confirming the GFSM in a graph format, and the 'Select ENV_IUT' is It shows all the tasks and threads used for the GFSM input, and allows the user to select the external environment (ENV) and testing target (IUT). 'State tour coverage' and 'Transition tour coverage' output Java and native test scripts for each test coverage.
[148] FIG. 5 is shown to show the detailed configuration of the native test driver 208 shown in FIG.
[149] In general, event transfer between tasks in embedded software is accomplished through a special function. In other words, when sending an event from the native task NT1 to NT2, the event transfer function acts as a delegate to put the event in the event queue of NT2. Therefore, in order to monitor an event occurring in the system, the native test driver 208 may be configured as shown in FIG. 4.
[150] Modify the event transfer function to send the original events to the native test driver (Monitored Events), and resending events from the native test driver to mark the original event so that they are not monitored repeatedly. Implement it to be identified by
[151] At this time, the components constituting the native test driver 208 include the following. First, you need a 'Script Parser' 502 that reads a test script for testing and controls according to its format. In this case, in the case of 'monitor', the 'Monitored Event Checker' 504 outputs the result of comparing the monitoring event with the event described in the script.
[152] In the case of 'assert' and 'condition', the 'System State Checker' 506 performs a comparison using a function that can read the state variable described above or directly accesses a global variable and outputs the result.
[153] In the case of 'message', the 'Input Event Generator' 508 generates a corresponding event and calls an event transmission function. At this time, the transmitted input event is generated to be not monitored like the retransmission event. Input events include not only simple events, but also events that require complex input data. In this case, the native test driver 206 is implemented to transmit input data prepared in advance in association with the 'data' format.
[154] FIG. 6 is shown to conceptually illustrate the operation of the Java test driver 206 shown in FIG.
[155] Since Java does not use a specific event transmission function as in native, the present invention uses a method of performing monitoring by modifying source code for transmitting a corresponding message as shown in FIG. 5 for Java monitoring.
[156] When the method you want to monitor is called (Event1), it also sends a message to the Java test driver thread. (Monitored Event1). When the Java test driver receives the monitored event, it reads the test script, performs the comparison, and outputs the result. In Java implemented in embedded software, only monitoring function is considered because input event from outside is always received from native task.
[157] However, these test drivers are subject to scheduling between threads. In other words, if JT2 is scheduled and then 'Event2' and 'Monitored Event2' are sent first after 'Event1' occurs in JT1 before sending 'Monitored Event1', the Java test driver inputs the monitored events in reverse order. Will receive.
[158] Therefore, as shown in FIG. 6, the Java test driver needs to check the system state every time an event is sent.
[159] In the case of a 'message' script that goes from the outside to the digital TV, a message may be directly generated by the native test driver 208 such as a remote controller input, but the actual broadcast data such as a broadcast stream may be used to test the system. That is, the system will not operate unless there is protocol data that follows the generated test sequence. Accordingly, the stream data is changed and used to generate a corresponding message, and the stream data is produced by the TS generator 210 at the request of the native test driver 208.
[160] However, since the data accepted by the system is in the form of a packet of 188 bytes, it is unreasonable to produce a packet with a simulator. Therefore, we construct the section data already produced. This is possible in order to make a broadcast stream in digital TV, there are section data encoding each protocol data, and these are used to create packet data by muxing with real video or audio and use it as input of the system. Use protocol data in the form of sections before testing.
[161] 7 shows a configuration of digital TV software to which an embodiment of the present invention is applied. SEC digital TV software to which the present invention is applied is a software implemented to satisfy the requirements of the US Digital ATSC (DASE) requirements, and operates on modules implemented in Java, pSOS operating system, and EsWin to provide a DASE API. It consists of native modules written in C language. The present invention describes the application of the proposed method to only a part of the functions of the SEC digital TV software shown in FIG.
[162] Tasks and threads configuring the DTV software shown in FIG. 7 include the following. First, there are native tasks (DBTK and SDFT) that perform the task of interpreting the application data contained in the received broadcast stream. At this time, the transmitted application is an HTML document, and the native task that shows it on the screen is BROWSER. AM (Application Manager) is a module that manages and executes information about application data to be broadcasted. This module provides application information on AL and Java, a native task that manages information about native applications. AM and ALAgent, which are managing threads, exist in the form of threads, and are used to exchange information between AM and AL using JNI (Java-Native Interface). The AppInfoViewer thread also manages the state of each Java application.
[163] Input events of the DTV software include data information through a broadcast stream and remote control input events. Data information through the broadcast stream is passed to DBAgent Java thread through DBTK and SDFT native tasks, which are managed by AM. Remote control inputs are passed to AL through EsWin (Embeded System Windows), to the native application task, or to AM using ALAgent. Other tasks and threads are tested for implementation under test (IUT). Input events through the broadcast stream include DB_DST_ARRIVED, which indicates the arrival of a table containing application information, and DV_DDL_INFO_ALLIVED, which indicates the arrival of actual application data. In addition, the inputs through the remote controller include VK_RC_TVVIDEO for executing an application, VK_RC_EXTI for terminating, and VK_RC_CH_UP and VK_RC_CH_DOWN for changing a channel.
[164] Message transmission between native tasks in DTV software is done using EsWin's EW_SendEventTask () function or pSOS's q_send (). In Java, there is a method for managing a queue for each thread. You can call this method when you want to send a message to a thread. State variables representing the state of the DTV software include currentApp, minor_channel, dst_version, and T_id, which indicate the state of the native task, and getState () and length, which indicate the state of the Java thread. currentApp is a variable that indicates the type of native application running. It has two values, AL_APP_NONE and AL_APP_PE. minor_channel is 1 or 2 to indicate the current channel, and dst_version is 0 or 0x40000000 as the version value of the application. length is the number of applications received, with a value of 0 or 1, and getState () is the state of an HTML application with four values: AM_UNINSTALLED, AM_HTML_INSTALLED, AM_HTML_ACTIVE, and AM_HTML_PAUSED. With this combination of state variables, the total number of possible states is 2 * 2 * 2 * 2 * 2 * 4 = 128. Considering that six input events can occur in each state, the total number of possible transitions is 128 * 6 = 768.
[165] When the functions of the digital TV software shown in FIG. 7 are described using the MSC, a total of 17 chapters are formed as shown in FIG. In the embodiment of the present invention, since the inline can be described only by alt, and it is assumed that the condition for selecting each alt item is completely described, dummy_munuShown_0, dummy_NONE, and dummy_EPG which have only an activation condition and do not perform any message transmission / reception , bMSCs like dummy_BROWSER are included.
[166] Six types of remote control or mouse selection inputs are processed with the digital TV-native as the top. AL processes the following messages after each scenario has been executed for each of the six message types sent from EsWin. MENU describes VK_RC_MENU, EXIT VK_RC_EXIT, EPG VK_RC_GUIDE, key_FAVORITE for VK_RC_FAV_CH, menu_FAVORITE for AL_FAVORITE_BUTTON_ID, and menu_BROWSER for AL_BROWSER_BUTTON_ID.
[167] The application termination scenario of FIG. 10 is referred to in the EXIT. When the VK_RC_EXIT input is input, the application termination scenario is activated when menuShown is 0. After the corresponding scenario (FIGS. 11, 12, and 13) is performed according to the value of currentApp The value of currentApp is stated to be AL_APP_NONE.
[168] In the present invention, the syntax of the bMSC is defined using only instance, message, condition, alt inline, and reference. In the case of bMSC using only the above factors, the MSC behavior can be assumed to be simply message transfer between processors. In other words, the syntax of the MSC can be thought of as an automata that accepts a sequence of events corresponding to an action. In the present invention, an automata that accepts a series of events is defined as a behavior automata, and finally, the GFSM is generated from the behavior automata.
[169] Prior to extracting the behavior automata of the MSC in the present invention, a simple message flow graph (sMFG: Simple MGF), which is an intermediate step for extraction, is defined. The simple message flow graph is similar to Ladkin's and Leue's work on MFGs, but differs in adding location information for behavioral automata extraction. Unit scenario Creates a node at the location where the message is sent and received at, and the condition, reference, and alt inline respectively. Then create a Bottom node where one instance ends. In the case of the position value of one node, natural numbers are given in order for each instance. Also, the ordering relationship between nodes in an instance In this case, we classify it as next event (ne) and the message order relation between instances In the case of a signal event (sig) was classified. The node on which the signal event corresponding to message m of the MSC occurs, that is, the outgoing message event. Nodes with! M, and incoming message events Nodes with have an event name of M. The sMFG obtained by applying this method to FIG. 14 is as shown in FIG. 15. In FIG. 15, a solid line indicates a signal event and a dotted line means next event.
[170] Each unit scenario Simple Message Flow Graph for G
[171] It can be defined as, each meaning is as follows.
[172] One. Is a set of events Same as the event set in.
[173] 2. Is a set of nodes.
[174] 3. Is a set of Bottom nodes.
[175] 4. Is a set of consecutive events.
[176] 5. Is a set of signal events.
[177] Is a set of next events, so it happens in one instance, so it can happen with Bottom, Is a set of signal events, so it doesn't happen with Bottom and it must always be another instance that sends and receives events. Node Is the name of the instance , The name of the event! M or M, and location information Is done. Location information Is a sequence of natural numbers assigned in order of ordering within an instance. These order values are used when defining the behavior automata. Similarly, Bottom node It is defined as Since Bottom doesn't have a signal event with another instance, it doesn't have an element corresponding to the event, and has a value of 0 as the position value.
[178] Based on the simple message flow graph G you define, you can define a behavior automata that represents the MSC's behavior as a sequence of events. The process of switching from the simple message flow graph to the behavior automata considers the vector of the location information corresponding to each instance as a state, and defines the vector of the changed location information as the next state when an event occurs. It is done by
[179] For example, as follows.
[180] The initial state is that no event has occurred. Therefore, in FIG. 14, all instances have a position value of 1. FIG. Therefore, this state <1,1,1,1> becomes the initial state of the behavior automata. The events that can occur in this state are a and b, so that the states <2,2,1,1> and <1,1,2,2>, when they occur, are added to the state of the behavior automata. Determining if an event can occur is obtained by the definition of a signal event, which is a set of signal events. This event can occur when the location values of nodes that originate in and receive match the instance location values of the current state. That is, signal events corresponding to the events of a and b in FIG. 13 are jIn1,! A, 1¿, jIn2, A, 1¿ and jIn4,! B, 1¿, jIn3, B, and 1¿. Here, all position values are 1, and the position of all instances of the current state is also 1. Thus, both a and b events can occur. The behavior automata obtained by applying this method to the simple message graph shown in FIG. 15 is shown in FIG.
[181] Act Automata The meaning of each is as follows.
[182] Q is a set of states.
[183] 2. Is a set of input events Is equivalent to a set of input events.
[184] 3. Is a set of transitions.
[185] 4. Is the initial state.
[186] 5. Is the final state.
[187] When there is a simple message flow graph G, the corresponding behavior automata BA can be obtained as follows. The initial state vector is ego, Has n elements. Also, the end state vector Same as
[188] Algorithm 1 Behavior Automata Extraction Algorithm
[189] 1: Q = {<1,1, ...>};
[190] 2: δ = θ;
[191] 3: do
[192] 4: let c = <i1, i2, ..., in> s.t. c∈Q;
[193] 5: for ∀sig ∈ SIG _G
[194] 6; let sig = (n1, n2) s.t
[195] 7: n1 = <i1,! E, l1>, n2 = <i2, E, l2>)
[196] 8: and p (q) th instance name is i1 (iw)
[197] 9: if ip = l1 and iQ = l2 then
[198] 10; Q = Q ∪ new s.t
[199] 11: new = <..., ip +1, ..., iq + 1, ...>;
[200] 12: δ = δ∪ (c, e_name (n1), NEW);
[201] 13: fi
[202] 14: rof
[203] 15: while some changes in Q
[204] Rows 1-2 of the behavior automata extraction algorithm initialize the Q and δ of the behavior automata. In the initial state, a vector with a position value of 1 for all processes becomes an initial state. Lines 5-9 look for events that can occur between configurations that belong to the current state. At this time, the method finds an event in which the instance location value of the location where the corresponding event occurs and the location value of both ends of the event match. Lines 10-12 are added by adding a transition for the case where a found event is raised, and constructing the post-event configuration by incrementing the position value of the instance that fired the event and receiving it. The obtained behavior automata becomes an automata that accepts a language of finite length, as shown in FIG.
[205] So far, only one bMSC We describe how can be converted into behavior automata. Since the specification of the system is linked to several MSCs, the behavior automata obtained in this way should also be connected. Since each item of Alt inline is written as a separate bMSC for reference, the behavior automata obtained from the referenced MSC can be connected in a branched form to complete the structure of the entire action automata. At this time, since the completed behavior automata is based on location information, there are many states. To make it meaningful, we put it into GFSM state using the state variable V used in the condition with assert.
[206] The detailed algorithm is as follows.
[207] 1. Obtain the behavior automata for the currently active bMSC.
[208] (a) Create a simple message flow graph for a given bMSC.
[209] (b) Extract the behavior automata by using the behavior automata extraction algorithm on the generated simple message flow graph.
[210] (c) There are other bMSCs that are referenced at this point and recursively obtain behavioral automata for them.
[211] (d) Complete the behavioral automata by linking the behavioral automata for the lower bMSC to the behavioral automata for the higher bMSC.
[212] 2. Find the state variables that appear in the behavior automata.
[213] It takes the initial values for each state variable into the initial configuration of the system and puts it on the stack.
[214] 4. Repeat the following steps until the stack is empty to generate GFSM.
[215] (a) Remove a system configuration from the stack and restart it if it has already been done.
[216] (b) If it is a new system configuration, it displays the system configuration.
[217] (c) For each transition connected to the initial node of the behavior automata:
[218] i. If the name of the transition is a condition that asks for an activation condition, it compares the state variables of the current system configuration and stops performing the current transition if it is not the same.
[219] ii. If the name of the transition is an assert that changes the value of a state variable, change the value of that state variable in the system configuration.
[220] iii. If the transitional node is the end node of the behavioral automata, one transition of the GFSM is completed, so the system configuration at the initial node of the behavioral automata is moved from_state to the set of transitions of the behavioral automata under the name of the transition and the behavioral automata. Outputs to_state the system configuration at the end node of.
[221] iv. The above process is recursively performed for the next node that can be reached by each viable transition.
[222] When the behavioral automata extraction algorithm is applied to the created digital TV software specification, a very large behavioral automata is formed. Here, the automata generated by the higher bMSC shown in FIG. 10 is shown in FIG. Each node of FIG. 17 is configured as information on the order and position information vector of the referenced bMSC. For example, the <app_EXIT> BROWSER_EXIT [0,0] node is a node representing the initial state of FIG. 12 and indicates that the BROWSET_EXIT scenario is referenced in the app_EXIT scenario. This is followed by a message label or a description of the conditional expression. For example, when the path described as 'currentApp = AL_APP_BROWSER' is executed, the path execution is terminated when the state variable value of the current system configuration is not like this. However, when executing the path described as 'assert currentApp = AL_APP_NONE', the state variable of the current system configuration is changed to the described value.
[223] When the GFSM generation algorithm is performed on the overall behavior automata generated as shown in FIG. 17, the GFSM as shown in FIG. 18 is obtained. At this time, menuShown is 0 and currentApp is AL_APP_NONE as the initial configuration of the system. The resulting GFSM consists of a total of six states and 30 transitions. The same number of states created as the combination of the two state variables is generated, but when applied to the entire digital TV system, only 152 of the 4608 possible states can be obtained. Since there are six possible inputs in six states, 36 transitions are possible, but the two state variables are changed by the icon selection input using a mouse, so six transitions are impossible. As such states and transitions that are possible in real systems are created, no states or transitions that are impossible as in conventional methods are included.
[224] Therefore, there is an advantage that can prevent the state explosion due to the intermediate generation result, not the state explosion due to the complexity of the system itself.
[225] As described above, the present invention discloses a specification-based automation method for testing interactions among tasks constituting embedded software.
[226] The automated method for software integration testing of the present invention introduces a method for describing interactions between tasks using an MSC, and generates a test sequence by generating a single GFSM representing the operation of the entire system from several bMSCs. We implemented an automated tool to do this.
[227] In addition, the implemented automation tools can be used for integrated testing of large, complex embedded software, enabling testing of task interactions that traditional testing tools could not perform.

权利要求:
Claims (39)
[1" claim-type="Currently amended] In a method for automatically generating test data based on interactions between tasks described by a message sequence chart, and automatically performing integration testing based on the generated test data,
(a) describing interactions between tasks of embedded software using message sequence charts;
(b) converting a transition between a state of a system that can be obtained by performing a plurality of message sequence charts and a state of a message sequence into a global finite state machine (GFSM);
(c) generating a test sequence from the written GFSM that can visit all states and transitions of the system; And
(d) An automated method for software integration testing that includes performing a generated test sequence using a test driver implemented on a simulator of embedded software.
[2" claim-type="Currently amended] The method of claim 1, wherein the step (a)
Among the syntaxes provided by the message sequence chart standard defined in ITU-T Z.120
Instance describing the task or thread to be specified, a Message describing the sending and receiving of messages between tasks, a Reference describing a reference to another basic message sequence chart, an Alt inline describing an optional scenario that can be performed, and whether the scenario has been performed. A method of automation for software integration testing, characterized by describing the interactions between tasks using five syntaxes: a condition describing an activation condition for determining a condition, or a condition describing a state change of a system by transmission of a message.
[3" claim-type="Currently amended] The method of claim 1, wherein (b)
(b-1) obtaining a behavior automata for the currently active bMSC;
(b-2) obtaining state variables appearing in the behavior automata;
(b-3) the initial value of each state variable as an initial configuration of the system and put in a stack;
(b-4) An automated method for software integration testing comprising repeating the process of creating nodes and transitions until the stack is empty to generate GFSM.
[4" claim-type="Currently amended] The method of claim 3, wherein (b-1)
(b-1-a) There are other bMSCs referenced here, and recursively determine the behavior automata for them,
(b-1-b) Automated method for software integration testing comprising connecting an action automata for a lower bMSC to an action automata for a higher bMSC to complete the entire action automata.
[5" claim-type="Currently amended] The method of claim 3, wherein (b-4)
(b-4-a) removing a system configuration from the stack and restarting if already done;
(b-4-b) displaying a new system configuration if the system configuration is performed;
(b-4-c) Automated method for software integration testing, characterized in that the following steps are repeated for each transition connected to the initial node of the behavior automata until the stack is empty.
[6" claim-type="Currently amended] The method of claim 5, wherein (b-4-c)
(b-4-c-i) If the name of the transition is a condition that asks for the activation condition, if it is not the same as the state variable value of the current system configuration, the execution of the current transition is stopped.
(b-4-c-ii) If the name of the transition is an assert that changes the value of a state variable, change the value of that state variable in the system configuration,
(b-4-c-iii) If the node due to transition is the end node of the behavior automata, one transition of the GFSM is completed, so the set of transitions of the behavior automata, which proceeds the system configuration from the initial node of the behavior automata to from_state To the state of the transition, and to_state the system configuration at the end node of the behavior automata, and
(b-4-c-iv) Automated method for software integration testing, characterized in that the above process is recursively performed for the next node that can be reached by each viable transition.
[7" claim-type="Currently amended] The test sequence of claim 1, wherein the test sequence generated in step (c) is described in a script form.
Message from to name parameter1 value1 ... format, monitor form to name parameter1 value1 ... format, to monitor the transfer of events between target tasks That is, condition task variable = value to check whether the system is in a proper state before interacting between tasks, assert task variable = value to indicate the condition of the test after performing the interaction, and current execution. An automated method for software integration testing characterized by using the form data variable1 value1 variable2 value2 ... to determine in advance which data to use for the test sequence to be performed.
[8" claim-type="Currently amended] The method of claim 1, wherein the step (c) uses only GSFM as an input, in which there is a transition from all states to initial states.
[9" claim-type="Currently amended] The method of claim 8, wherein step (c)
An automated method for software integration testing, characterized by generating a test sequence by combining a short test path algorithm with a depth first search.
[10" claim-type="Currently amended] The method of claim 9, wherein step (c)
(c-1) All states (or metastases) are marked as not visited.
(c-2) Put the initial state of GFSM into a queue and make an empty path.
(c-3) obtaining and outputting the states that can be visited from the initial state and the corresponding paths until the queue is empty; And
(c-4) If any of the states (or transitions) have not been visited yet, put the first of them in the input order and perform 3 again. And if the obtained state is not the initial state, storing the shortest path from the initial state to this state.
[11" claim-type="Currently amended] The method of claim 10, wherein (c-3)
(c-3-a) Get a state from the queue.
(c-3-b) Get the state that can go from the imported state.
(c-3-c) Find the new (or transition to the saved) ones you have not yet visited.
(c-3-d) Among the states (or transitions) that have not yet been visited, the first one is selected in the order entered, added to the route, and marked as visited.
(c-3-e) Queue the selected state.
(c-3-f) if a new state (or transition) is not available, outputting the path that has been progressed and the shortest path from the current state to the initial state and emptying the path;
[12" claim-type="Currently amended] The process of claim 11, wherein the outputting of the shortest path in (c-3-f) is performed.
(c-3-f-i) Collects all the conditions in the MSC 'condition' statement on the obtained path and outputs them in the 'data' format at the beginning of the test sequence. The test driver prepares input data for testing by referring to the test driver;
(c-3-f-ii) outputting messages indicating a transition; And
(c-3-f-iii) Compares the values of variables before and after transition and outputs all the values before the change in 'condition' format, and then outputs 'message' or 'monitor' corresponding to the transition in order. And then output all the changed values in the form of 'assert'.
[13" claim-type="Currently amended] The method of claim 12, wherein (c-3-f-ii)
-If the event sending task is ENV, it is 'message'. Otherwise, it is prefixed with 'monitor'.
-If the event sending and receiving tasks are all Java threads starting with ':', the automated method for software integration testing, characterized in that the Java test script outputs the rest to the native test script.
[14" claim-type="Currently amended] The method of claim 1, wherein the embedded software includes a native task implemented in C language and a thread implemented in JAVA language.
The message sequence of step (a) and the GFSM of step (b) have information about a native task and a thread.
In the step (c), the test sequence for the native task and the test sequence for the thread are generated separately.
[15" claim-type="Currently amended] 15. The method of claim 14, wherein step (d) includes a native test driver that performs a test for a native task in response to a test sequence for the native task, and a java for performing a test for the thread in response to a test sequence for a thread. An automated method for software integration testing, characterized by being performed by a test driver.
[16" claim-type="Currently amended] The method of claim 15,
And a test result by monitoring an event transmission function of the native task.
[17" claim-type="Currently amended] 17. The method of claim 16, wherein the test result is checked by causing an event transfer function of the native task to send an event to the native test driver.
[18" claim-type="Currently amended] The method of claim 17,
And transmitting and marking an original event so that the native test driver does not repeatedly monitor the event from the native test driver.
[19" claim-type="Currently amended] The method of claim 15,
And when the method to be monitored in the java task is called, transmits an event to the java test driver and examines the test result.
[20" claim-type="Currently amended] The method of claim 19,
And the java test driver checks a system state each time an event is received so that events transmitted by scheduling between threads are not inverted.
[21" claim-type="Currently amended] The method of claim 2,
And (d) generating protocol data for the broadcast stream according to the test sequence generated in step (d).
[22" claim-type="Currently amended] The method of claim 21,
In the protocol data generation process, the section data encoding the protocol data is generated and provided to the test driver.
The step (d) is an automated method for software integration testing, characterized in that for generating a message provided to the task using the section data.
[23" claim-type="Currently amended] An apparatus for automatically generating test data based on interactions between tasks described by a message sequence chart and automatically performing integrated testing based on the generated test data.
Create a message sequence chart describing the interactions between tasks in the embedded software, and use the Global Finite State to show the transitions between the state of the system and the state by the sequence of messages that can be achieved by the execution of the various created message sequence charts. Message sequence chart editor for converting;
A test sequence generator for generating a test sequence capable of visiting all states and transitions of the system from the created GFSM; And
An automated device for software integration testing that is implemented on a simulator of embedded software and includes a test driver for executing a test sequence generated by the test sequence generator.
[24" claim-type="Currently amended] The method of claim 23, wherein the message sequence chart editor
Among the syntaxes provided by the message sequence chart standard defined in ITU-T Z.120
Instance describing the task or thread to be specified, a Message describing the sending and receiving of messages between tasks, a Reference describing a reference to another basic message sequence chart, an Alt inline describing an optional scenario that can be performed, and whether the scenario has been performed. Automated device for software integration testing characterized by describing the interaction between tasks using five syntaxes of condition describing the activation condition to determine the state or the state change of the system by sending the message.
[25" claim-type="Currently amended] 24. The method of claim 23, wherein the test sequence generator generates a test sequence in the form of a script, and the script is used to send an input event from an external environment to a task to be tested from an external environment. Monitor form to name parameter1 value1 ... format, GFSM transitions to monitor the transmission of events, that is, condition task variable = value format, to check whether the system is in an appropriate state before interaction between tasks. Use the assert task variable = value format to indicate the test condition after performing an action, and the data variable1 value1 variable2 value2 ... format to know in advance which data to use for the test sequence to be performed. Automation device for software integration testing, characterized in that
[26" claim-type="Currently amended] 27. The automated apparatus of claim 25, wherein the test sequence generator uses only GSFM as input as a transition from all states to initial states.
[27" claim-type="Currently amended] The method of claim 23, wherein the embedded software includes a native task implemented in the C language and a thread implemented in the JAVA language.
The message sequence chart editor generates a message sequence GFSM having information about a native task and a thread together.
The test sequence generator is an automated device for software integration testing, characterized in that for generating a test sequence for a thread and a test sequence for the native task separately
[28" claim-type="Currently amended] The test driver of claim 27, wherein the test driver performs a test for a thread in response to a test sequence for a thread and a native test driver for performing a test for a native task in response to a test sequence for the native task. Automation device for software integration testing comprising a
[29" claim-type="Currently amended] The method of claim 28,
The native test driver is an automated device for software integration testing, characterized in that the test results are monitored by monitoring the event transfer function of the native task.
[30" claim-type="Currently amended] 30. The apparatus of claim 29, wherein the native test driver receives an event transmitted by an event transmission function of a native task and inspects a test result.
[31" claim-type="Currently amended] The method of claim 30,
The native test driver is an automated device for software integration testing, characterized in that the original event to be transmitted so as not to be repeatedly monitored in transmitting the event to the native task.
[32" claim-type="Currently amended] The method of claim 28,
The java test driver receives an event transmitted when a method to be monitored in the java task is called and inspects a test result.
[33" claim-type="Currently amended] 33. The method of claim 32,
The java test driver checks the system state every time an event is received so that events transmitted by scheduling between threads are not reversed.
[34" claim-type="Currently amended] The method of claim 27,
The apparatus further includes a transport stream generator for generating protocol data for a broadcast stream according to the test sequence generated by the test sequence generator.
[35" claim-type="Currently amended] The method of claim 34, wherein
The transport stream generator generates section data encoding the protocol data and provides the test data to the test driver.
The test driver generates a message provided to the task using the section data, the automated device for software integration testing
[36" claim-type="Currently amended] In the method of determining the behavior of the system-wide behavior automata based on the interaction between the tasks described in the Message Sequence Chart,
(b-1) obtaining a behavior automata for the currently active bMSC;
(b-2) obtaining state variables appearing in the behavior automata;
(b-3) the initial value of each state variable as an initial configuration of the system and put in a stack;
(b-4) A method for determining an automata, including generating a GFSM by repeating the process of creating nodes and transitions until the stack is empty.
[37" claim-type="Currently amended] The method of claim 36, wherein (b-1)
(b-1-a) If there are other bMSCs referenced at this point, recursively obtain the behavior automata for them,
(b-1-b) A method for determining the behavior automata, wherein the behavioral automata for the lower bMSC is connected to the behavioral automata for the higher bMSC to complete the entire behavioral automata.
[38" claim-type="Currently amended] The process of claim 36, wherein (b-4)
(b-4-a) removing a system configuration from the stack and restarting if already done;
(b-4-b) displaying a new system configuration if the system configuration is performed;
(b-4-c) A method for determining the behavior automata, which repeats the following process for each transition connected to the initial node of the behavior automata until the stack becomes empty.
[39" claim-type="Currently amended] The process of claim 38, wherein (b-4-c)
(b-4-c-i) If the name of the transition is a condition that asks for the activation condition, if it is not the same as the state variable value of the current system configuration, the execution of the current transition is stopped.
(b-4-c-ii) If the name of the transition is an assert that changes the value of a state variable, change the value of that state variable in the system configuration,
(b-4-c-iii) If the node due to transition is the end node of the behavior automata, one transition of the GFSM is completed, so the set of transitions of the behavior automata, which proceeds the system configuration from the initial node of the behavior automata to from_state To the state of the transition, and to_state the system configuration at the end node of the behavior automata, and
(b-4-c-iv) A method for determining the behavior automata, characterized in that the above process is recursively performed for the next node that can be reached by each viable transition.

类似技术:

---

公开号 | 公开日 | 专利标题

---

KR20180122018A|2018-11-09|Configuring Pattern-Driven Responses in Real-Time Data Flow Programming

---

Tyan2002|Design, realization and evaluation of a component-based compositional software architecture for network simulation

---

US7734775B2|2010-06-08|Method of semi-automatic data collection, data analysis, and model generation for the performance analysis of enterprise applications

---

US6208345B1|2001-03-27|Visual data integration system and method

---

US6996801B2|2006-02-07|System and method for automatically generating program

---

Chung et al.2002|NS by Example

---

US7693974B2|2010-04-06|System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network

---

US5930480A|1999-07-27|Software architecture for controlling data streams based on linked command blocks

---

CA2605118C|2012-01-10|Development tool and method for automating detection and construction of notification based component applications

---

USRE38641E1|2004-10-26|Isochronous channel having a linked list of buffers

---

Mozumdar et al.2008|A framework for modeling, simulation and automatic code generation of sensor network application

---

EP2148259B1|2016-12-28|Field device management apparatus and field device management system

---

US6182119B1|2001-01-30|Dynamically configurable filtered dispatch notification system

---

DE60030618T4|2008-04-10|Event control device and digital broadcasting system

---

JP3949667B2|2007-07-25|Test stream creation method and apparatus for supporting various standards and test levels

---

EP2127221B1|2012-05-16|A method and system for monitoring messages passed over a network

---

US6324576B1|2001-11-27|Management interworking unit and a method for producing such a unit

---

US20120284696A1|2012-11-08|Method, Apparatuses and a System for Compilation

---

US7616568B2|2009-11-10|Generic packet generation

---

US5954829A|1999-09-21|System, method, and computer program product for digital cross connect testing

---

US9584391B2|2017-02-28|User-configurable network performance monitors

---

EP1727045A2|2006-11-29|Application framework for use with net-centric application program architectures

---

JP4087466B2|2008-05-21|Method and apparatus for generating an interactive component data stream representing an application program for an audio-video interactive composite signal

---

JP2005228227A|2005-08-25|Thin client system and its communication method

---

US20060047665A1|2006-03-02|System and method for simulating an application for subsequent deployment to a device in communication with a transaction server

同族专利:

---

公开号 | 公开日

---

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

法律状态:
2001-06-15|Application filed by 삼성전자 주식회사

---

2001-06-15|Priority to KR1020010033906A

---

2002-12-28|Publication of KR20020095723A

优先权:

---

申请号 | 申请日 | 专利标题

---

KR1020010033906A|KR20020095723A|2001-06-15|2001-06-15|Method and apparatus for integrated testing of software|